-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: disable background throttling #12181
base: dev
Are you sure you want to change the base?
feat: disable background throttling #12181
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks so much. If nothing major changes in the Wry PR i only have 2 very small comments:
Co-authored-by: Fabian-Lars <[email protected]>
Package Changes Through ce3cb33There are 10 changes which include tauri-cli with minor, @tauri-apps/cli with minor, tauri-build with patch, tauri-runtime with minor, tauri-runtime-wry with minor, tauri-utils with minor, tauri with minor, @tauri-apps/api with minor, tauri-bundler with patch, tauri-driver with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
@FabianLars I changed the comments according to your suggestions and also updated the wry PR with a version check. Let me know if there is anything else I should do before this PR can be merged. |
…tner/tauri into feat/background-throttling-pr
…tner/tauri into feat/background-throttling-pr
I changed the wry version to |
This PR relates to #5250
It requires a change of
wry
for which I've opened another PR: tauri-apps/wry#1445I've added an option
disableBackgroundThrottling
to allow developers to choose if their view should automatically be throttled / suspended by the browser after a certain time of being hidden or minimised. In the worst case, this default behaviour of browsers can lead to broken applications running in the background.For instance if a websocket connection is the only reason not to suspend a "tab" and the machine goes into sleep mode and wakes up again, the connection is often lost and the browser won't have any reason to keep the background tab active and therefore unload it, which will not allow the hidden view to "heal" itself.
This default behaviour effectively renders any browser capabilities unusable for long running background processes. One alternative might be moving logic from the frontend to the backend, but browsers have meanwhile become a great choice for local first apps and if the browser already offers the required features easily accessible, why force developers to leave a territory they feel comfortable with?
As of now, this is only available for WebKit based browsers on iOS 17.0+,iPadOS 17.0+,Mac Catalyst 17.0+, macOS 14.0+, visionOS 1.0+ ( see https://developer.apple.com/documentation/webkit/wkpreferences/inactiveschedulingpolicy-swift.enum?language=objc ).
It can be assumed that it will also be implemented for WebView2 (Windows). And it might be that it's already usable for linux and android, although I couldn't find any documentation about it and also cannot test it locally due to a lack of devices.
As an alternative for windows and non-webkit browsers, one can setup a pending WebLock transaction, which, according to the docs, can also keep the browser from suspending it.
I needed to update a snapshot test and am unsure if this is at all related to this change. Please let me know if I did something wrong here.
Pending Tasks
wry
package version when feat: disable background throttling wry#1445 is merged, which will havewith_disable_background_throttling
onWebViewBuilder